Methods and systems are known for creating and maintaining backup copies of a primary database which can be used in place of the primary database should the primary database become unavailable. The backup and primary databases are typically maintained on separate systems at remote locations, to reduce the possibility that a disruptive event will affect both databases. Changes made to the primary database are typically logged and then applied to the backup database to keep the backup database up-to-date with the primary database. Furthermore, the logged changes can also be re-applied to the primary database to recover from a disaster affecting the primary database. Like the backup system, the change logs are typically shipped to and kept at a location remote from the primary system.
Important considerations in disaster recovery planning with regard to any database management system (DBMS) such as DB2 (from International Business Machines of Armonk, New York) in which log records are used to rebuild the system, are how to get the log records offsite to a remote location and how often. Currently, a typical solution is to create copies of the log datasets and ship them to the remote site on some type of regular schedule, e.g., once a day. However, if a disaster should occur at the primary site hours after the logs are created and shipped offsite, a large amount of data may be lost, requiring re-entry of many transactions into the primary system.
In the case of recovering individual database objects, such as a DB2 tablespace, a major source of delay in the recovery process is the reading of the DB2 log. The log not only contains information for the tablespace being recovered, it also contains log information for the entire system including other objects which are not of interest. As a result, a large amount of unneeded data may be read in order to perform the recovery of a single tablespace.
Existing products such as R+/CHANGE ACCUM from BMC Software, Inc. of Houston, Tex. and MERGE/MODIFY from Platinum Technology, Inc. of Oakbrook Terrace, Ill., offer a mechanism to extract log data from the DB2 log to create proprietary datasets containing only the pertinent log data for one or more selected tablespaces. This can help eliminate unnecessary I/O operations. Nonetheless, these processes still need to be scheduled. This may still require that unneeded log datasets be read to catch any updates that were made since the last time the proprietary datasets were created.